Most mobile services and applications are based on an architecture referred to as the client-server model. This system includes a server to service the requests of several smaller computers (e.g., mobile communication devices), which connect to the server and may be referred to as clients. The client devices typically do not communicate with each other but exchange data with the server. The server and the client establish a connection with each other, which typically passes through a plurality of routers (or nodes). Each node between the server and the client may also be referred to as a hop.
To ensure proper routing of the messages between the server and the intended mobile client, the messages are broken up into data packets, each of which receives a destination address according to a consistent protocol. The packets are reassembled upon being received by the intended or target client. The Internet Protocol (IP) is an acceptable protocol for exchanging information between a server and client. A Transmission Control Protocol (TCP) may be used in conjunction with the IP, and may provide for a reliable stream delivery of messages.
A TCP connection is designed to be maintained between two hosts in the multi-hop network for an arbitrary period of time and as long as the hosts are operational. It is not necessary that the TCP connection carries any traffic. With the growth of access networks (such as private or home networks), a network typically includes a NAT or NAPT (Network Address (Port) Translation) functionality. The NAT functionality is often implemented in a network access node (in home networks typically a wireless router) that serves the access network comprising a plurality of hosts (often terminals) connected to the access node. The access node is in turn connected to the core network (the Internet) through a network interface. Each host in the access network is allocated a unique private IP address. Normally, an Internet Service Provider (ISP) allocates only one public IP address per network interface. So, in order to allow more than one host in the access network to communicate towards the internet using only one public IP address, the Network Address Translation (NAT) functionality is necessary. The functionality of a NAT/NAPT is described, for example, in the Internet document RFC 3022.
The presence of NAT functionality in a network impacts the durability of established TCP connections. Many NATs are implemented with TCP binding timers for each established connection. A TCP binding timer is basically a timer that expires when no packets on a certain TCP connection have passed the NAT for a certain period of time. When the timer expires, the TCP connection is released by the NAT and needs to be re-established again if any new data packets have to be sent. The NATs have these binding timers due to physical limitations of the NAT. A NAT can only keep a finite number of connections in its memory. A common policy is therefore to release old and inactive connections. Some NATs can have other implementations to solve these physical limitations. One way is to have a finite priority list of established connections. As soon as a packet is sent on a certain connection, that connection is put on top of the priority list. When establishing a new connection through the NAT, the connection that was at the bottom of the priority list is released if there is no memory left to store bindings for the new connection.
This means that a TCP connection that is intended to be maintained between two hosts for a long time (for example a connection between a client and a presence server) simply is released by the NAT if no packets have been sent during a certain period of time.
One way to provide or maintain an “always-on” connection is to send keep-alive messages/packets (which may also be referred to as “heartbeat” messages) at a sufficiently high rate to keep the NAT open. Keep-alive messages are dummy TCP data packets. The packets are sufficient to reset the NAT binding time and keep the connection alive.